S3（Simple Storage Service）是物件儲存服務——存進去的東西是完整的「物件」（object），不是一顆硬碟或一個檔案系統。每個物件放在一個 bucket（儲存桶）裡，用一個 key（鍵，通常長得像路徑，例如 logs/2026/09/access.log）當唯一識別碼，物件不支援像檔案系統那樣的局部修改，存取單位是整個物件：寫入是整份覆蓋，讀取是整份下載。
Bucket 名稱在整個 AWS（不只是自己的帳號）裡必須唯一。一個物件的位置寫出來長這樣：
s3://my-app-logs/logs/2026/09/access.log
└── bucket ┘└──────── key ─────────┘
S3 的設計耐用度是 11 個 9（99.999999999%），物件遺失的機率極低——但耐用度不等於可用性，可用性依儲存類別不同而有落差，下面會看到。讀寫一致性是強一致：寫入或覆蓋成功後，馬上讀一定拿到最新版本，不會讀到舊的。
同一份資料，S3 依照「多久會被存取一次」分成好幾種儲存類別，價格跟這個存取頻率成反比；差別不只在價錢，還包括資料實際存在幾個 AZ（AZ 數量，數字越大代表單一 AZ 故障時越不會受影響），以及要多久才能真的讀到內容（取用速度）：
| 儲存類別 | 適合情境 | AZ 數量 | 取用速度 |
|---|---|---|---|
| S3 Standard | 常態存取（一個月不只一次） | ≥3 | 毫秒 |
| S3 Intelligent-Tiering | 存取模式不確定或會變 | ≥3 | 毫秒（選用的歸檔層例外） |
| S3 Standard-IA | 不常存取（約一個月一次），但要保留唯一一份、不能重建的資料 | ≥3 | 毫秒 |
| S3 One Zone-IA | 不常存取、資料弄丟可以重建（例如複寫出來的副本） | 1 | 毫秒 |
| S3 Glacier Instant Retrieval | 約每季存取一次，但要即時讀到 | ≥3 | 毫秒 |
| S3 Glacier Flexible Retrieval | 約每年存取一次，可以等 | ≥3 | 分鐘～數小時 |
| S3 Glacier Deep Archive | 幾乎不存取的長期封存 | ≥3 | 數小時～48 小時 |
IA（Infrequent Access） 指的就是「不常存取」。One Zone-IA 只存在一個 AZ，便宜但沒有 AZ 故障的容錯能力，AWS 官方建議只拿它放「弄丟了也能重建」的資料，例如另一個 bucket 已經有正本的複寫副本。
便宜的類別不是白給的，每一種都有附帶條件：可用性是 AWS SLA 承諾「隨時讀得到資料」的比例，數字比耐用度低很多，代表偶爾會撲空、要重試；取回要錢嗎則是除了每月的儲存費之外，把物件實際讀出來這個動作要不要另外按 GB 收費。這張表是後面算成本時真正會用到的：
| 儲存類別 | 最短計費天數 | 最小計費大小 | 可用性 | 取回要錢嗎 |
|---|---|---|---|---|
| Standard | 無 | 無 | 99.99% | 不用 |
| Intelligent-Tiering | 無 | 無（小於 128 KB 不監控、留在 Frequent 層） | 99.9% | 不用，但每個物件有監控費 |
| Standard-IA | 30 天 | 128 KB | 99.9% | 每 GB 收 |
| One Zone-IA | 30 天 | 128 KB | 99.5% | 每 GB 收 |
| Glacier Instant Retrieval | 90 天 | 128 KB | 99.9% | 每 GB 收 |
| Glacier Flexible Retrieval | 90 天 | 每物件另加 40 KB 中繼資料 | 99.99%（還原後） | 每 GB 收，依速度分級 |
| Glacier Deep Archive | 180 天 | 每物件另加 40 KB 中繼資料 | 99.99%（還原後） | 每 GB 收，依速度分級 |
「最小計費大小 128 KB」的意思是：一個 10 KB 的物件放在 Standard-IA，照 128 KB 收費。所以一堆小檔案丟進 IA 類別，反而可能比留在 Standard 貴。
它不是一個固定的類別，而是一個會自己換層的容器。物件放進去先在 Frequent Access 層，連續 30 天沒被讀就降到 Infrequent Access 層，連續 90 天沒讀再降到 Archive Instant Access 層——這三層都還是毫秒取用，讀了會自動升回 Frequent。另外還有兩個要自己打開的歸檔層：Archive Access（90 天以上沒讀）和 Deep Archive Access（180 天以上沒讀），這兩層取用要先還原、要等，開了才會用到。代價是每個物件每月一筆小額監控費，換來的是不用自己猜存取模式。
三個 Glacier 類別裡，只有 Glacier Instant Retrieval 是毫秒等級、跟 Standard 一樣直接讀。下面這張表只講另外兩個——Flexible Retrieval 和 Deep Archive：它們的物件是「封存」狀態，讀之前要先發 restore 請求，S3 做出一份暫存副本放一段你指定的天數才能讀，取回速度目前分三級，快慢對應不同價格（以下時間區間是 AWS 目前公告的數字，實際以當下文件為準）：
| Expedited | Standard | Bulk | |
|---|---|---|---|
| Glacier Flexible Retrieval | 1～5 分鐘 | 3～5 小時 | 5～12 小時 |
| Glacier Deep Archive | 沒有這個選項 | 約 12 小時 | 約 48 小時 |
「稽核要在幾小時內拿到」和「即時讀取」是兩種完全不同的需求，前者 Flexible Retrieval 的 Standard 就夠，後者只能用 Instant Retrieval 或 IA 類別。
上面那張表是「有哪些類別」，但物件不會自己知道該去哪一類。Lifecycle 規則負責這件事：幫 bucket（或用前綴、標籤篩選出來的一群物件）設定「滿幾天就搬到哪個類別」，甚至「滿幾天就整個刪掉」。一條規則寫出來大概是這樣：
規則名稱：archive-logs
套用範圍：key 前綴 logs/ 的所有物件
動作
滿 30 天 → 轉到 Standard-IA
滿 90 天 → 轉到 Glacier Flexible Retrieval
滿 365 天 → 過期刪除
另外：未完成的 multipart upload 超過 7 天 → 清掉（不然殘片會一直計費）
搬遷方向只能單向往下（AWS 官方稱為 waterfall model）：從 Standard 可以搬去 Standard-IA、Intelligent-Tiering、One Zone-IA 或任一 Glacier 系列，但 Glacier Flexible Retrieval 之後只能再轉到 Deep Archive，轉進 Deep Archive 之後就不能再用 Lifecycle 轉走——要拿回來，得先「還原」（restore）出一份暫存副本。
規則有三個限制：
Bucket 有開 Versioning 的話，規則可以分別針對「目前版本」和「舊版本」設定：舊版本設定為保留 30 天後刪除，是常見的一種寫法。
| 主題 | 說明 |
|---|---|
| Versioning（版本控制） | 開啟後，同一個 key 被覆蓋或刪除時，舊版本會留下來而不是消失；「刪除」變成加一個 delete marker，可以復原。Cross-Region Replication 的前提就是這個 |
| Cross-Region Replication（CRR） | 把物件自動複寫到另一個 Region 的 bucket，來源和目的地 bucket 都要先開 Versioning；常搭配 One Zone-IA 當目的地類別，因為複本弄丟了，來源那份還在 |
| S3 Object Lock | WORM（write once, read many）模式，鎖定物件在一段期間內不能被刪除或覆寫。Governance 模式允許有特定權限的人繞過；Compliance 模式連 root 帳號都鎖得住 |
| Storage Class Analysis | S3 內建的分析工具，觀察物件實際存取頻率，輔助判斷該不該把某群物件轉去 Standard-IA，本身不會自動搬遷，仍要人另外設定規則 |
| 同 Region 複寫（SRR） | 跟 CRR 一樣的機制，只是目的地在同一個 Region，用途是把多個 bucket 的 log 彙整到一個，或是正式／測試環境同步一份資料 |
儲存類別的選擇依據是存取頻率，不是資料的重要性；生命週期規則讓這個判斷自動執行，但小物件的轉移門檻與各類別的最短計費天數，都會影響實際節省的成本。
某公司在 S3 中保存法遵稽核用的交易紀錄，這些檔案平均每季會被稽核人員存取一次，但每次被要求提供時都必須立即（幾秒內）讀取到完整內容，不能有還原等待時間。公司希望在滿足這個存取模式的前提下，把儲存成本降到最低。
哪一種儲存類別最符合這個需求？
某公司在 S3 建立了一條生命週期規則，套用在
archive/前綴的物件：第 30 天轉到 S3 Glacier Flexible Retrieval，第 60 天再轉到 S3 Glacier Deep Archive。設定儲存後，主控台顯示規則驗證失敗，無法儲存生效。工程師確認前綴、Effect 都沒有打錯字。
這條規則失敗的原因最可能是什麼，應該怎麼修改？
某公司受金融法規要求，特定 S3 bucket 中的合約文件在建立後 7 年內不得被任何人刪除或覆寫，即使是擁有
s3:*權限的帳號管理員或 root 使用者也不行。公司同時要求，這些文件要在另一個 Region 保留一份唯讀副本，以防單一 Region 發生區域性事故。
解決方案架構師應該如何設定，才能同時滿足這兩項要求？
某公司每天產生數百萬個平均大小約 8 KB 的應用程式 log 檔案，儲存在 S3 Standard。為了省錢，工程師設定生命週期規則，滿 30 天就把這些物件轉移到 S3 Standard-IA。轉移後檢查帳單，儲存費用不但沒有下降，反而比留在 Standard 時更高。
造成帳單不減反增的原因最可能是什麼？
某公司在 S3 儲存使用者上傳的多媒體檔案，存取模式因內容熱度而波動、很難預測；同時營運團隊過去發生過幾次工程師手滑刪除物件的事故，公司希望之後即使物件被覆蓋或刪除，都能夠復原到刪除前的版本，且不想自己寫程式分析存取模式來決定該轉哪個儲存類別。
解決方案架構師應該建議哪兩項做法？（選擇兩項）
Glacier Instant Retrieval 的存取速度是毫秒級，符合「立即讀取」的要求，而它設計給的存取頻率正好是大約每季一次，持續儲存成本比其他能立即讀取的類別更低。
B 技術上也能立即讀取，但它設計給大約每月一次的存取頻率，拿來放每季才讀一次的資料，持續儲存的單位成本會比 Glacier Instant Retrieval 貴。D 的讀取要先發 restore 請求、等待分鐘到數小時，不符合「立即讀取」。A 雖然便宜又是毫秒讀取，但只存在一個 AZ、沒有容錯，適合的是弄丟了可以重建的資料，不適合稽核紀錄這種必須保留的正本。
Glacier Flexible Retrieval 的最短計費天數是 90 天，同一條規則裡兩段轉移之間，至少要間隔滿前一個類別的最短天數；原規則第 30 天轉入、第 60 天就轉出，只隔了 30 天，把第二段改到第 120 天（30＋90）以後才符合這個限制。
B 是誤解：同一條 Lifecycle 規則本來就可以在裡面設定多段轉移，不需要拆成多條規則。C 方向錯了：Lifecycle 是單向的 waterfall，物件轉進 Glacier Flexible Retrieval 後只能再往 Deep Archive 走，不能反向轉回較「熱」的類別。D 也是誤解：key 前綴篩選完全支援多段轉移，不存在「前綴只能轉一次」這種限制，問題不在篩選條件上。
S3 Object Lock 必須先在 bucket 啟用 Versioning 才能使用，Compliance 模式在保留期內連 root 使用者都無法刪除或覆寫物件，滿足「任何人都不能刪」的最嚴格要求；搭配在另一個已啟用 Versioning 的 Region bucket 設定 Cross-Region Replication，則滿足異地備援的要求。
A 的 Governance 模式允許擁有特定權限的人繞過保留設定，IAM Deny 規則也管不到 root 使用者，不符合「連 root 都不行」的要求。B 漏了前提：S3 Object Lock 要求 bucket 必須先啟用 Versioning 才能設定，沒開 Versioning 就無法套用，而且 AWS Backup 每天備份的頻率也達不到即時的異地保護。C 把保護責任丟給應用程式自己加 header，但 Object Lock 必須先在 bucket 層級啟用才會真正生效，單靠上傳時加的 legal hold 標頭而不啟用 bucket 層級設定不會被強制執行。
Standard-IA 對小於 128 KB 的物件仍以 128 KB 計費，8 KB 的 log 檔案轉過去後，每個物件的計費大小暴增超過 15 倍；雖然 Standard-IA 的每 GB 單價比 Standard 低，但小物件被墊高的計費大小抵銷甚至超過了單價下降帶來的節省，導致整體帳單不減反增。
A 誇大了一次性轉移請求費的影響，這筆費用遠小於持續性的儲存費差異，不足以解釋帳單顯著上升。B 的天數寫錯了：Standard-IA 的最短計費天數是 30 天，不是 90 天（90 天是 Glacier Instant Retrieval 與 Flexible Retrieval 的門檻）。D 憑空假設了題幹沒提到的讀取行為，題目只說明是為了省錢做轉移，沒有任何證據顯示讀取模式改變或有取回費用發生。
Intelligent-Tiering 會依物件實際的存取狀況，在 Frequent、Infrequent 等存取層之間自動搬移，不用自己分析或預測存取模式；Versioning 則讓物件被覆蓋或刪除時保留舊版本（刪除只是加上 delete marker），符合「能復原到刪除前版本」的要求。
B 是誤解：Storage Class Analysis 只負責分析、提供建議，本身不會自動搬遷物件，仍然要另外設定 Lifecycle 規則才會真的移動。C 違反可用性期待：One Zone-IA 只存在一個 AZ、沒有跨 AZ 容錯，而且它是固定類別，不會依存取頻率自動搬遷。E 的 Cross-Region Replication 解決的是異地備援，不是「自動依存取頻率分層」或「復原被覆蓋／刪除的版本」這兩個訴求。
iThome鐵人賽
看影片追技術